Location verification and secure no-fly logic for unmanned aerial vehicles

ABSTRACT

Apparatus, methods and systems to associate a flight plan of an unmanned aerial vehicle (e.g., a drone) with a cryptographic signature are disclosed herein. Some disclosed examples include one or more non-transitory computer-readable media including computer-executable instructions. The computer readable instructions, when executed by one or more processors, cause the one or more processors to compare a flight path over a geographic area of an unmanned aerial vehicle to a geographically identified no-fly zone. The flight path is included in a flight plan. The instructions also cause the vehicle to determine whether the flight path enters the geographically identified no-fly zone, and based on whether the flight path is determined to enter the geographically identified no-fly zone, associate the flight plan with a cryptographic signature.

RELATED APPLICATION

This patent arises from a continuation of U.S. patent application Ser.No. 14/839,395, (Now U.S. Pat. No. ______) which was filed on Aug. 28,2015. U.S. patent application Ser. No. 14/839,395 is hereby incorporatedherein by reference in its entirety. Priority to U.S. patent applicationSer. No. 14/839,395 is hereby claimed.

BACKGROUND

With the advent of modern technology, unmanned aerial vehicles (UAV's),also referred to as drones, have become widely available for militaryuse, commercial use, and consumer use. As drones become more widespread,the potential as a target for hacking or other attempts to control,divert, or otherwise interfere with operation or flight of the drone islikely to increase. In particular, autonomous drones may be a desirabletarget for such attempts. Moreover, the implementation of flight pathsthat ignore flight restrictions (such as restricted airspace above ornear an airport) may be another challenge. Some drone components, suchas open-source hardware and/or software, may be susceptible to attemptsby a user, a hacker, or other persons to implement such flight paths.

BRIEF DESCRIPTION OF THE FIGURES

The detailed description is set forth with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Theuse of the same reference numbers in different figures indicates similaror identical items.

FIG. 1 is a schematic diagram of an environment illustrating a droneengaged in autonomous flight in accordance with an example embodiment ofthe disclosure;

FIG. 2 is a schematic diagram depicting an environment illustratinglocation verification of the drone of FIG. 1 in accordance with anexample embodiment of the disclosure;

FIG. 3 is a block diagram of a process for determining whether tovalidate a location of a drone determined from satellite-basedpositioning data in accordance with an example embodiment of thedisclosure;

FIGS. 4A and 4B (collectively FIG. 4) is a block diagram of a processfor determining a process for validating a location of a dronedetermined from satellite-based positioning data in accordance with anexample embodiment of the disclosure;

FIG. 5 is a schematic diagram of a drone implementing no-fly zone logicin accordance with an example embodiment of the disclosure;

FIG. 6 is a block diagram of a process for the initialization of animplementation of secure no-fly zone logic in accordance with anembodiment of the disclosure; and

FIG. 7 is a block diagram of a process for verifying and using a flightplan with an implementation of secure no-fly logic described herein inaccordance with an example embodiment of the disclosure.

Certain implementations will now be described more fully below withreference to the accompanying drawings, in which various implementationsand/or aspects are shown. However, various aspects may be implemented inmany different forms and should not be construed as limited to theimplementations set forth herein; rather, these implementations areprovided so that this disclosure will be thorough and complete, and willfully convey the scope of the disclosure to those skilled in the art.Like numbers refer to like elements throughout.

DETAILED DESCRIPTION

Embodiments herein relate to, among other things, location verificationfor autonomous unmanned aerial vehicles (also referred to as “drones”).In some embodiments, an unmanned aerial vehicle engaged in autonomousflight may determine its location using a satellite-based navigationsystem. The location may be evaluated using an initial validation todetermine whether the location is valid. If the location is not valid,the location may be further evaluated against location data obtainedfrom one or more secondary factors, such as public broadcast beacons,cellular towers, wireless network identifiers, visual markers, or anycombination thereof. If the location is determined to be invalid, theunmanned aerial vehicle may be instructed to take a mitigation action.If the location is determined to be valid, the location may be storedand the unmanned aerial vehicle may continue autonomous flight.

In some embodiments, the flight plan for an unmanned aerial vehicle maybe verified using secure no-fly logic. A no-fly zone control module maybe implemented as a platform enclave stored in the memory of an unmannedaerial vehicle. The NFZC module may obtain no-fly zone data from aserver or use previously stored no-fly zone data to verify a flight plandoes not violate any known no-fly zones. If the flight plan is verified,the flight plan may be signed using a cryptographic signature associatedwith the NFZC enclave. The signed flight plan is provided to anavigation module that verifies the signature and executes the flightplan. If the flight plan is not verified, the navigation module is notable to verify the flight plan and the flight plan is not used by thenavigation module.

FIG. 1 depicts an environment 100 illustrating an unmanned aerialvehicle 102 engaged in autonomous flight in accordance with anembodiment of the disclosure. In some embodiments, the unmanned aerialvehicle 102 may be associated with and, in some embodiments maycommunicate with, a base station 104. In some embodiments, a user 106may communicate with the unmanned aerial vehicle 102 via the basestation 104. In some embodiments, the unmanned aerial vehicle 102 mayalso be capable of being remotely piloted by the user 106 via the basestation 104.

The unmanned aerial vehicle 102 may communicate with a satellite-basednavigation system 110 to determine its location. For example, theunmanned aerial vehicle 102 may engage in autonomous flight usinglocations determined using the satellite-based navigation system 110,such as via the use of a flight plan having one or more predeterminedlocations.

FIG. 1 depicts various components of the unmanned aerial vehicle 102,although it should be appreciated that various components are omittedand embodiments of the unmanned aerial vehicle 102 may includeadditional components not illustrated in FIG. 1. As shown in FIG. 1, theunmanned aerial vehicle 102 may include a processor 112 (e.g., one ormore processors), a receiver 114 (e.g., one or more receivers) and amemory 116 (e.g., one or more memories). The processor 112 may providethe processing capability to execute the operating system, programs,user interface, and other functions of the unmanned aerial vehicle 102.For example, the processor 112 may execute various modules stored in thememory 116 and provide commands to the unmanned aerial vehicle 102, suchas for navigation and flight. The processor 112 may include one or moreprocessors and may include microprocessors, application-specificintegrated circuits (ASICs), or any combination thereof. In someembodiments, the processor 112 may include one or more reducedinstruction set (RISC) processors, such as those implementing theAdvanced RISC Machine (ARM) instruction set. Additionally, the processor112 may include single-core processors and multicore processors and mayinclude graphics processors, video processors, and related chip sets.Multiple processors may be employed to provide for parallel orsequential execution of the techniques described herein. Processes, suchas logic described herein may be performed by the processor 112executing one or more computer programs to perform functions byoperating on input data and generating corresponding output.

The receivers 114 may include any number of receivers for communicationusing suitable wireless communication protocols and technologies. Forexample, the receiver 114 may include a receiver for communication witha satellite-based navigation system (e.g., the Global Positioning System(GPS), Global Navigation Satellite System (GLONASS), Galileo, etc.).

The memory 116 (which may include one or more tangible non-transitorycomputer readable storage mediums) may include volatile memory, such asrandom access memory (RAM), accessible by the processor 112 and othercomponents of the unmanned aerial vehicle 102. For example, the memory116 may store executable computer code, such as the firmware for theunmanned aerial vehicle 102, an operating system for the unmanned aerialvehicle 102, and any other programs or other executable code forproviding functions of the unmanned aerial vehicle 102.

The memory 116 may include various modules and other components forenabling operation and flight of the unmanned aerial vehicle 102. Forexample, as shown in FIG. 1, the memory 116 may include a locationmodule 118 that determines the location of the unmanned aerial vehicle102 using the satellite-based navigation system 110. The memory 116 mayalso include a location verification module 120 that verifies thelocation determined from the satellite-based navigation system 110 inaccordance with the techniques described herein. In some embodiments,the memory 116 may also store maps 122 usable by the locationverification module 120 or other modules or components of the unmannedaerial vehicle 102. In some embodiments, the maps 122 may include a mapof public broadcast beacons, a topological map, or other maps. In someembodiments, the maps 122 may be generated by the unmanned aerialvehicle 102 during a previous survey along a flight path, such as byidentifying visual markers along the flight path, identify the locationsof wireless network identifiers along the flight path, and so on.

In some embodiments, the unmanned aerial vehicle 102 may also include acamera 124. For example, the camera 124 may capture still images, video,or both of areas surrounding the unmanned aerial vehicle 102 (e.g., theground beneath the unmanned aerial vehicle, the area in front theunmanned aerial vehicle, etc.). In some embodiments, the camera 124 maybe of sufficient resolution to enable image-recognition performed onobjects captured in the camera's field of view.

FIG. 2 depicts an environment 200 illustrating location verification ofthe unmanned aerial vehicle 102 in accordance with an embodiment of thedisclosure. As described above, the unmanned aerial vehicle 102 mayfollow a flight plan using locations determined from a satellite-basednavigation system 110. For example, the unmanned aerial vehicle 102 mayautonomously fly along a flight path portion 202 and may determine andverify locations 204 along the flight path portion 202. FIG. 2 alsoillustrates an intended flight path portion 206 of the unmanned aerialvehicle 102. However, in some environments a signal allegedly receivedfrom the satellite-based navigation system 110 may instead be a spoofedsignal 208 that may relay incorrect navigation data to the unmannedaerial vehicle 102. Thus, instead of following the intended flight pathportion 206, the unmanned aerial vehicle 102 may fly along actual flightpath portion 210 as a result to the incorrect navigation data providedby the spoofed signal 208. Thus, the position determinations performedby the unmanned aerial vehicle 102 may result in the unmanned aerialvehicle 102 determining that it is at a location along intended flightpath 206, when the actual position of the unmanned aerial vehicle 102 isalong actual flight path 210. For example, a spoofed signal transmitted100 meters north of an actual satellite-based navigation system signalcould cause the unmanned aerial vehicle 102 to deviate from an intendedflight path such that the unmanned aerial vehicle may unable to completea task, may crash into an obstruction, land in an unsafe landing area(e.g., a roadway) and so on. It should be appreciated that the spoofedsignal 208 is merely one example of an event that may cause the unmannedaerial vehicle 102 to deviate from the intended flight plan and, inother embodiments, other events may cause similar deviations. Forexample, other events may include broadcast attacks that also cause theunmanned aerial vehicle to deviate from the intended flight path portion206.

As described below, the unmanned aerial vehicle 102 may rely onadditional data captured by the unmanned aerial vehicle 102 to validatethe location determined from the satellite-based navigation data. Thecapture of location data may involve the use of secondary factorsdifferent from a satellite-based navigation system and described furtherbelow. Thus, if the location validation module 120 of the unmannedaerial vehicle 102 determines a conflict between the location data andthe location determined from the satellite-based positioning data,various actions may be taken by the unmanned aerial vehicle 102.

FIG. 2 depicts multiple sources of location data that may be used by theunmanned aerial vehicle 102 to validate its location. In someembodiments, the secondary factors may include a public broadcast beacon212, a wireless access point 214, visual markers 214 below or around theunmanned aerial vehicle, and a cellular tower 216. Additionally, othersources of data may include weather information received from publiclyavailable weather sources, the location and distance to the unmannedaerial vehicle's base station, and other suitable sources. Theadditional location data may be used to validation a location determinedfrom the satellite-based navigation data. If the location is not valid,a mitigation action may be taken by the unmanned aerial vehicle, asdescribed further below.

FIG. 3 depicts a process 300 for determining whether to validate alocation in accordance with an embodiment of the disclosure. In someembodiments, some or all steps of the process 300 may be implemented inthe location module 118, the location validation module 120, or acombination thereof.

Initially, as described above, the location of an autonomous unmannedaerial vehicle may be determined from satellite-based positioning data(block 302). The location is evaluated using an initial validation todetermine if the location is invalid (block 304). In some embodiments,the initial validation includes comparing the location to a signalreceived from the unmanned aerial vehicle's base station. The differencebetween the location and data derived from or in the signal may becompared to each other or to a threshold. In some embodiments, thedistance between the location and the base station and the unmannedaerial vehicle's range may be compared. For example, if the locationindicates the unmanned aerial vehicle is 100 kilometers from the basestation but the unmanned aerial vehicle's range is only 2 km, thelocation may be determined to be invalid under the primary invalidation.

If the location is invalid under the initial validation (line 306), thenthe location is validated using one or more secondary factors, asdescribed further in FIG. 4. If the determined location is not invalidunder the initial validation (line 308), then a timer is evaluated todetermine whether a time interval has elapsed (block 310). The timer maybe a part of the location validation module 120 described above. Thetimer may specify a time interval for performing a location validation,regardless of whether the initial validation determined a validlocation. Accordingly, at every time interval indicated by the timer,the location of the unmanned aerial vehicle may be validating using thesecondary factors in the manner described herein. In some embodiments,the time (and the timer interval) may be configured by a user or may beconfigured for a specific unmanned aerial vehicle, base station, etc. Ifthe timer has not elapsed (line 312), the determined location may bestored by the unmanned aerial vehicle and the unmanned aerial vehiclemay continue autonomous flight (block 314).

If the timer has elapsed (line 316), the location may be validated usingone or more secondary factors (block 318), as described in FIG. 4. Thevalidation using the one or more secondary factors may determine whethercorrective action is needed by the unmanned aerial vehicle (block 320).If corrective action is not needed (line 322), the determined locationmay be stored by the unmanned aerial vehicle and the unmanned aerialvehicle may continue autonomous flight (block 314).

If corrective action is needed (line 324), the availability of analternative location source may be determined (block 326). In someembodiments, the determination of an alternative location source mayinclude evaluation of the accuracy and confidence of a locationdetermined from one or more secondary factors, as described below. If analternative location source is available (line 328), the alternativelydetermined location may be stored by the unmanned aerial vehicle and theunmanned aerial vehicle may continue autonomous flight (block 314). Forexample, in some embodiments an alternative location source may asecondary factor such as one or more public broadcast beacons. If alocation determined from one or more public broadcast beacons exceeds anaccuracy threshold and a confidence threshold, the one or more publicbroadcast beacons may be used as an alternative location source. If analternative location source is not available (line 330), then theunmanned aerial vehicle may be instructed to execute a mitigation action(block 332).

FIGS. 4A and 4B depict a process 400 for validating a locationdetermined from satellite-based positioning data using secondary factorsin accordance with an embodiment of the disclosure. In some embodiments,some or all steps of the process 300 may be implemented in the locationmodule 118, the location validation module 120, or a combinationthereof.

Initially, as shown in FIG. 4A, the availability of one or more publicbroadcast beacons may be determined (block 402), such as by evaluatingsignals broadcast by the one or more public broadcast beacons. Suchpublic broadcast beacons may include public broadcast beaconsspecifically for unmanned aerial vehicle navigation and locationdeterminations. If one or more public broadcast beacons are available(line 404), location data may be determined using the public broadcastbeacons (block 406) and the location data may be stored (block 408). Insome embodiments, the available one or more public broadcast beacons maybe compared to a stored map (e.g., map 122) of public broadcast beaconsto determine location data. In some embodiments, the map may include therange of one or more public broadcast beacons.

If one or more public broadcast beacons are not available (line 410),then the availability of one or more cellular towers for a locationdetermination may be determined (block 412). If one or more cellulartowers are available (line 414), location data may be determined usingthe cellular towers (block 416) and the location data may be stored(block 408). In some embodiments, the available one or more cellulartowers may be compared to a stored map (e.g., map 122) of cellulartowers to determine location data. In some embodiments, the map mayinclude the range of one or more cellular towers.

If one or more cellular towers are not available (line 418), then theavailability of one or more wireless network identifiers (e.g., aService Set Identifier (SSID) transmitted from a wireless access point)for a location determination may be determined (block 420). If one ormore wireless network identifiers are available (line 422), locationdata may be determined using the one or more wireless networkidentifiers (block 424) and the location data may be stored (block 426).In some embodiments, the available one or more wireless networkidentifiers may be compared to a stored map (e.g., map 122) of wirelessnetwork identifiers to determine location data. In some embodiments, themap may include the range of one or more wireless network identifiers.

If one or more wireless network identifiers are not available (line426), then the availability of one or more visual markers for a locationdetermination may be determined (block 428). In some embodiments, thevisual markers may be captured by a camera (e.g., camera 122) of theunmanned aerial vehicle 102. For example, as an unmanned aerial vehicleflies over a landscape, the camera may capture visual markers such aslandmarks, buildings, natural topographical features (e.g., rivers,lakes, mountains, etc.) and the like. If one or more visual markers areavailable (line 430), location data may be determined using the one ormore wireless network identifiers (block 432) and the location data maybe stored (block 426). For example, a visual marker may be compared to atopographical map having various markers to determine location data.

If one or more visual markers are not available (line 434), then theunmanned aerial vehicle may be instructed to execute a mitigation action(block 436). The mitigation actions may include, for example,immediately landing the unmanned aerial vehicle (e.g., turning on anunmanned aerial vehicle camera and attempt to land safely without theuse of satellite-based positioning data), returning to the last locationvalidated by a minimum number of secondary factors (e.g., returning toone of the locations 204 illustrated in FIG. 2), returning to the basestation, sending a request to the base station for human-controlledflight, or self-destruction. In some embodiments, the mitigation actionsmay be selected or prioritized by a user or for a specific type ofunmanned aerial vehicle, base station etc.

In other embodiments, additional or alternative secondary factors may beused to obtain location data. In some embodiments, the range from a basestation associated with the unmanned aerial vehicle may be used aslocation data. In some embodiments, the current weather conditions atthe determined location may be used as location data. Additionally, insome embodiments a secondary factor may be disabled by a user such thesecondary factor is not used in the location validation.

In some embodiments, the priority of secondary factors used for locationdata may be specified by a user or for a specific type of unmannedaerial vehicle, base station etc. For example, public broadcast beaconsmay be prioritized over cellular towers, cellular towers may beprioritized over wireless network identifiers, and so on. In someembodiments, the number of secondary factors used for location data maybe specified by a user or for a specific type of unmanned aerialvehicle, base station etc.

In some embodiments, a minimum number of available secondary factors maybe specified by a user or for a specific type of unmanned aerialvehicle, base station etc. For example, a user could configure thelocation validation module such that the determined location may only beinvalidated if location data from at least two secondary factors shownan error with the location. In some embodiments, the minimum number ofsecondary factors may be based on the initial validation describedabove. For example, if the initial validation first invalidates thelocation, location data from only secondary factor may be used. In yetother embodiments, a minimum number of individual secondary factors maybe specified by a user or for a specific type of unmanned aerialvehicle, base station etc. For example, in such embodiments at least twoWi-Fi SSID's, at least two public broadcast beacons, etc. may be neededbefore the secondary factor may be used for location data.

As shown by connector block A, the process 400 continues in FIG. 4B. Asshown in FIG. 4B, the stored location data may be compared to thelocation determined from the satellite-based positioning data (block440) to determine an error factor and, in some embodiments, a confidencevalue associated with the error factor. In such embodiments, thedistance between the determined location and one or more secondaryfactors and a range associated with the one or more secondary factors(e.g., public broadcast beacon, cellular tower, wireless networkidentifier, base) may be used to determine an error factor. For example,if the unmanned aerial vehicle can detect a Wi-Fi identifier up to 300ft away but the location and stored map indicates the unmanned aerialvehicle is 1000 ft from the Wi-FI network associated with theidentifier, an error factor may be determined.

In some embodiments, the error factor may be a distance. In someembodiments, the error factor may be a multiple of the differencebetween the location and the location data determined from one or moreavailable secondary factors. In some embodiments, the error factor maybe an average of error factors associated with two or more secondaryfactors, a weighted average of error factors associated with two or moresecondary factors, and so on. In some embodiments, the visual markersecondary factor may be compared to a stored map that includes thedetermined location to determine an error factor. For example, if thedetermine location on a stored map is over a road but the visual markerindicates a building, an error factor may be determined. In someembodiments, the confidence value may be determined from a particularsecondary factor, as some secondary factors may have a higher confidencevalue for an error factor determination than other secondary factors.

The error factor may be compared to a threshold (block 442) to determinewhether the location is valid. In some embodiments, the threshold may beselected based on a particular secondary factor, a confidence value, orboth. If the locations are within the threshold (line 444), the locationis determined to be valid and the unmanned aerial vehicle may store thelocation and continue autonomous flight (block 446).

If the error factor is above the threshold (line 448), the location maybe determined to be invalid (block 450). In some embodiments, thelocation data may be evaluated to determine if the location data exceedsan accuracy threshold and a confidence threshold (block 452). Forexample, a wireless network identifier may have a range of 100 ft andmay thus provide location data at a granularity in the 100s of ft. Incontrast, a visual marker may be viewable at a 1000 ft and may thusprovide location data at a granularity in the 1000s of ft.

If the location data is above the accuracy threshold and the confidencethreshold (line 454), the secondary location may recorded and theunmanned aerial vehicle may continue autonomous flight (block 446). Ifthe secondary location is not above the accuracy threshold andconfidence threshold (line 456), corrective action may be taken (block458), as described in block 320 and the corresponding portions of theprocess 300 illustrated in FIG. 3.

In some environments, no-fly zones may be present that prohibit theflying of unmanned aerial vehicles in some airspace. As described below,embodiments of the disclosure may include an unmanned aerial vehiclehaving secure no-fly zone logic that prevents operation of the unmannedaerial vehicle and user circumvention of the prevention unless a flightplan has been verified against no-fly zone data. FIG. 5 depicts a system500 having an unmanned aerial vehicle 502 implementing the no-fly zonelogic described herein. The unmanned aerial vehicle 502 may be capableof autonomous flight, user-controlled flight or both. In someembodiments, as described further below, the unmanned aerial vehicle 502may communicate with a server 504 via a network 506.

FIG. 5 depicts various components of the unmanned aerial vehicle 502,although it should be appreciated that various components are omittedand embodiments of the unmanned aerial vehicle 502 may includeadditional components not illustrated in FIG. 5. For example, someembodiments may include an unmanned aerial vehicle that implements boththe unmanned aerial vehicle components and flight validation logicdescribed above and illustrated in FIG. 1 and the unmanned aerialvehicle components and secure no-fly logic illustrated in FIG. 5 anddescribed below.

As shown in FIG. 5, the unmanned aerial vehicle 502 may include aprocessor 508 (e.g., one or more processors), a network interface 510(e.g., one or more interfaces) a memory 512 (e.g., one or morememories), and local storage 514 (e.g., one or more non-volatile memorydevices that provide local storage of data). The processor 508 may besimilar to the processor 112 described above and may execute variousmodules stored in the memory 512 and provide commands to the unmannedaerial vehicle 502, such as for navigation and flight.

The memory 512 may be similar to the memory 116 described above and mayinclude various modules and other components for implementing the secureno-fly logic describe herein and for providing navigation of theunmanned aerial vehicle. For example, as shown in FIG. 5, the memory 512may include a flight plan calculator 516, a policy manager 518, anavigation module 520, and no-fly zone compliance (NFZC) enclave 522. Asused herein, the term “enclave” refers to a protected area in an addressspace of the memory 512, such that attempts to access the enclave memoryarea from modules or other software not resident in the enclave areprevented. In some embodiments, the NFZC enclave 522 may be implementedusing an isolated execution software model, such as Software GuardExtensions (SGX) provided by Intel, Inc. of Santa Clara, Calif.

In some embodiments, the navigation module 520 may also be implementedusing an enclave, such that the navigation module is protected fromaccess via modules or other software not resident in its enclave. Inother embodiments, the navigation module may be implemented in firmwareusing a secure boot technology, as described below. In yet otherembodiments, the navigation module may be implemented using a protectedservice, such as a service implemented using a virtualization technology(VT).

The local storage 514 may include non-volatile memory, such as read-onlymemory (ROM), flash memory, a hard drive, other suitable optical,magnetic, or solid-state storage mediums, or any combination thereof.The memory 514 may store data files such as media (e.g., music and videofiles), software (e.g., for implementing functions on the unmannedaerial vehicle 502), wireless connection information, and any othersuitable data.

The network interface 510 may include any number of interfaces forcommunication using suitable network (e.g., wireless networks, wirednetworks, or both) communication protocols and technologies. The networkinterface 510 may implement any suitable communications standard,protocol and technology, Ethernet, Global System for MobileCommunications (GSM), Enhanced Data GSM Environment (EDGE), a 3G network(e.g., based upon the IMT-2000 standard), high-speed downlink packetaccess (HSDPA), wideband code division multiple access (W-CDMA), codedivision multiple access (CDMA), time division multiple access (TDMA), a4G network (e.g., IMT Advanced, Long-Term Evolution Advanced (LTEAdvanced), etc.), Bluetooth, Wireless Fidelity (Wi-Fi) (e.g., IEEE802.11 standards), voice over Internet Protocol (VoIP), Wi-Max, or anyother suitable communications standards, protocols, and technologies.

The flight plan calculator 516 may calculate a flight plan from receiveddata (e.g., one or more locations such as an origin, a destination,waypoints, etc.). For example, a user may input one or more locationsand the flight plan calculator 516 may calculate a flight plan using amap, satellite-based positioning data, or other data. The policy manager518 may provide for policy enforcement of various flight policies, suchas flight policies specific to the unmanned aerial vehicle type, theflight plan, etc. For example, such policy enforcement may include theenforcement of no camera zones, altitude restrictions, rangerestrictions, speed limits, etc.

As described further below, the NFZC enclave 522 may securely obtain andstore no-fly zone data 524. In some embodiments, the no-fly zone datamay include geographic identification of no-fly zones in a geographicarea. Using the no-fly zone data 524, the NFZC enclave 522 may verifycompliance of a flight plan (calculated by the flight plan calculator516) with the no-fly zone data. For example, the NFZC enclave 522 maycompare the geographic path of a flight plan with no-fly zones todetermine whether the flight plan violates a no-fly zone. If the flightplan does not violate a no-fly zone, the NFZC enclave 522 may verify theflight plan for use by the navigation module. In some embodiments, theNFZC enclave may also annotate a flight plan with policies such as nocamera zones, altitude restrictions, range restrictions, speed limits,etc.

The NFZC enclave 522 may also include a cryptographic signature 526 forsigning verified flight plans. The cryptographic signature 526 may usebe implemented using any number of and suitable encryption algorithm,including asymmetric encryption algorithms such as RSA, Diffie-Hellman,Digital Signature Standard (DSS), elliptical curve cryptography (ECC). Averified flight plan 528 may be signed using a cryptographic signatureand, after verification, may be provided to the navigation module 520for use in flying the unmanned aerial vehicle. The navigation module 520may include verification logic that verifies the cryptographic signature526, such that the navigation module 520 only executed flight planssigned by the NFZC enclave 522.

In some embodiments, the NFZC enclave 522 may obtain the no-fly zonedata 524 from the server 504. For example, the NFZC enclave 522 may sendtransmit a request for no-fly zone data (e.g., new or updated no-flyzone data) to the server 504. The server 504 may include a processor 530and a storage 532 that stores no-fly zone data for geographic areas(e.g., no-fly zone data 524). The server 504 may be a single server (ina discrete hardware component or as a virtual server) or multipleservers. The server 504 may include web servers, application servers, orother types of servers. Additionally, the server 504 may be, forexample, computers arranged in any physical and virtual configuration,such as computers in one or more data processing centers, a distributedcomputing environment, or other configuration. Such configurations mayuse the network 506 for communication or may communicate over othernetworks.

The unmanned aerial vehicle 502 and the server 504 are in communicationwith the network 506, such as through a wired or wireless networkinterface. In some embodiments, the network 506 may include multiplenetworks, and may include any suitable network and networkingtechnology, such as the Internet, an intranet, a local area network(LAN), a wide area network (WAN), or any other suitable network.Additionally, the network 506 may include a wired network, a wirelessnetwork, or both. Moreover, it should be appreciated that the unmannedaerial vehicle 502 and the server 504 may communicate over differentnetworks separately and simultaneously. For example, the unmanned aerialvehicle 502 may communicate over both a wireless Ethernet network and acellular network.

Upon receiving a request for no-fly zone data from an unmanned aerialvehicle 502, the server 504 may transmit a response having no-fly zonedata (e.g., new or updated no-fly zone data) to the unmanned aerialvehicle 502. In some embodiments, the NFZC enclave 522 may encrypt thereceived no-fly zone data 524 and store the encrypted no-fly zone data536 on local storage 514. In some embodiments, if the NFZC enclave 522is unable to communicate with the server 504 to obtain no-fly zone data,the NFZC enclave 522 may use the stored no-fly zone data 536 to verify aflight plan.

FIG. 6 depicts a process 600 for the initialization of an NFZC enclavein accordance with an embodiment of the disclosure. Initially, anunmanned aerial vehicle may be powered on using a secure boot process(block 602). In some embodiments, the secure boot process may beimplemented using the unified extensible firmware interface (UEFI). Insome embodiments, the secure boot process may enable the execution ofsoftware (e.g., an operating system, software modules) associated withvalid credentials but disallow the execution of software without validcredentials. In some embodiments, the credentials may include a digitalsignature (which may refer to or include a cryptographic signature).

After boot-up, a secure connection to a server may be attempted toretrieve no-fly zone data (block 604), and the connection may beverified (block 606). In some embodiments, the secure connection mayinclude a connection using the Transport Layer Security (TLS) protocoland the Secure Sockets Layer (SSL) protocol (in some embodiments, theSSL and TSL designations may refer to the same protocol). In someembodiments, the secure connection may be implemented using a pinnedcertificate, a remote attestation (e.g., implemented using SGX providedby Intel, Inc. of Santa Clara, Calif., other security protocols ortechniques, or any combination thereof.

If the connection is verified (line 608), a determination of whether theno-fly zone data is or includes new data may be performed (block 610).For example, in some embodiments the determination may be performed bycomparing a version number of the no-fly zone data stored on theunmanned aerial vehicle with a version number of the no-fly zone dataavailable from the server. If the no-fly zone data is or includes newdata (line 612), the no-fly zone data may be obtained (block 614). Theobtained no-fly zone data is then encrypted and stored on local storage(block 616) and the NFCZ enclave may report that it is ready to validateflight paths (block 618).

If the connection to the server is not verified (line 620), the no-flyzone data previously encrypted and stored on local storage may bedecrypted (block 622) for use by the NFZC enclave. Similarly, if theno-fly zone data on the server is not or does not include new data (line624), the no-fly zone data previously encrypted and stored on localstorage may be decrypted (block 622) for use by the NFZC enclave.

In some embodiments, the age or version of the no-fly zone datapreviously encrypted and stored on local storage may be evaluatedagainst an age or version threshold (block 626) (e.g., by evaluating atimestamp associated with the no-fly zone data against the current dateto determine the age of the no-fly zone data, by evaluating a versionnumber of the no-fly zone data, etc.). If the no-fly zone data is olderthan the age or version threshold (line 628), an error may be reportedand the unmanned aerial vehicle may be powered off or otherwise disabled(block 630). If the no-fly zone data is less than the age threshold(line 632), the NFCZ enclave may report that it is ready to validateflight paths (block 618).

FIG. 7 depicts a process 700 for verifying and using a flight plan withthe secure no-fly logic described herein in accordance with an exampleembodiment of the disclosure. As shown in FIG. 7, various portions ofthe process 700 may be performed by the flight path calculator module702, the NFZC enclave 704, and the navigator module 706. However, inother embodiments the process 700 may be distributed differently acrosssuch modules or using different modules or arrangements thereof.

Initially, a flight plan may be calculated (block 702), such as by theflight plan calculator module described above, and the calculated flightplan may be sent to the NFZC enclave (block 704). Next, the NFZC enclavemay verify the flight plan against the no-fly zone data (block 706),such as the no-fly zone data obtained during the initialization of theNFZC enclave described above and illustrated in FIG. 5 to determinewhether the flight plan is compliant with the known no-fly zones (block708). If the flight plan is not compliant with the no-fly zones (line710), an error may be reported (block 712). In some embodiments, theflight plan calculator module may recalculate a flight plan in anattempt to avoid no-fly zones. In some embodiments, the error report mayinclude no-fly zone data that enables a user to resubmit locations or aflight plan that attempts to avoid the no-fly zones.

If the flight plan is compliant with the known no-fly zones in theno-fly zone data (line 714), the flight plan may be annotated with knownpolicies (block 716) and signed with the NFZC enclave's cryptographicsignature (block 718) e.g., a binary large object (blob) that includesthe flight plan may be signed with the cryptographic signature. In someembodiments, upon validation, the flight plan may be annotated withother information such as no camera zones, speed limited zones, etc.

The signed flight plan may be obtained by the navigator module (block720) and, in some embodiments, the cryptographic signature may beverified (block 722). For example, in some embodiments the cryptographicsignature may be implemented using asymmetric cryptography such that thenavigation module includes or has access to a public key for decryptinga signed flight plan encrypted by the NFZC enclave's private key.However, in other embodiments other cryptographic signing andverification techniques may be used.

If the cryptographic signature is unable to be verified (line 724), anerror may be reported (block 726). If the cryptographic signature isverified (line 728), the flight plan annotations associated with theflight plan may be provided to a policy manager (block 730). Asdescribed above, the policy manager may implement and enforce policiesassociated with a flight plan, such as by shutting off a camera when theunmanned aerial vehicle is in a no-fly zone, etc. The verified flightplan may be executed by the navigation module (block 732) to enableflying of the unmanned aerial vehicle using the flight plan. In someembodiments, an obstacle may be encountered during the flight ofunmanned aerial vehicle (block 734) that may result in a re-route of theunmanned aerial vehicle's flight. If no obstacle is encountered (line736), the verified flight plan may continue to be executed (block 730)such that the unmanned aerial vehicle maintains flight according to theverified flight plan. If an obstacle is encountered during flight (line738), a new flight plan may be calculated (block 702) and re-verifiedaccording to the process 700 described above.

Certain aspects of the disclosure are described above with reference toblock and flow diagrams of systems, methods, apparatuses, and/orcomputer program products according to various implementations. It willbe understood that one or more blocks of the block diagrams and flowdiagrams, and combinations of blocks in the block diagrams and the flowdiagrams, respectively, can be implemented by computer-executableprogram instructions. Likewise, some blocks of the block diagrams andflow diagrams may not necessarily need to be performed in the orderpresented, or may not necessarily need to be performed at all, accordingto some implementations.

These computer-executable program instructions may be loaded onto aspecial-purpose computer or other particular machine, a processor, orother programmable data processing apparatus to produce a particularmachine, such that the instructions that execute on the computer,processor, or other programmable data processing apparatus create meansfor implementing one or more functions specified in the flow diagramblock or blocks. These computer program instructions may also be storedin a computer-readable storage media or memory that can direct acomputer or other programmable data processing apparatus to function ina particular manner, such that the instructions stored in thecomputer-readable storage media produce an article of manufactureincluding instruction means that implement one or more functionsspecified in the flow diagram block or blocks.

As an example, certain implementations may provide for a computerprogram product, comprising a computer-readable storage medium having acomputer-readable program code or program instructions implementedtherein, said computer-readable program code adapted to be executed toimplement one or more functions specified in the flow diagram block orblocks. The computer program instructions may also be loaded onto acomputer or other programmable data processing apparatus to cause aseries of operational elements or steps to be performed on the computeror other programmable apparatus to produce a computer-implementedprocess such that the instructions that execute on the computer or otherprogrammable apparatus provide elements or steps for implementing thefunctions specified in the flow diagram blocks.

Accordingly, blocks of the block diagrams and flow diagrams supportcombinations of means for performing the specified functions,combinations of elements or steps for performing the specified functionsand program instruction means for performing the specified functions. Itwill also be understood that each block of the block diagrams and flowdiagrams, and combinations of blocks in the block diagrams and flowdiagrams, can be implemented by special-purpose, hardware-based computersystems that perform the specified functions, elements or steps, orcombinations of special-purpose hardware and computer instructions.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainimplementations could include, while other implementations do notinclude, certain features, elements, and/or operations. Thus, suchconditional language is not generally intended to imply that features,elements, and/or operations are in any way required for one or moreimplementations or that one or more implementations necessarily includelogic for deciding, with or without user input or prompting, whetherthese features, elements, and/or operations are included or are to beperformed in any particular implementation.

Many modifications and other implementations of the disclosure set forthherein will be apparent having the benefit of the teachings presented inthe foregoing descriptions and the associated drawings. Therefore, it isto be understood that the disclosure is not to be limited to thespecific implementations disclosed and that modifications and otherimplementations are intended to be included within the scope of theappended claims. Although specific terms are employed herein, they areused in a generic and descriptive sense only and not for purposes oflimitation.

Further Embodiments

In a first example embodiment there is disclosed a non-transitorycomputer-readable medium storing computer-executable instructions. Whenexecuted by a processor, the computer-executable instructions cause theprocessor to perform operations that include obtaining a location of anunmanned aerial vehicle engaged in autonomous flight. The location maybe determined from a satellite-based navigation system. When executed bya processor, the computer-executable instructions further cause theprocessor to perform operations that include determining location datafrom one or more sources accessible by the unmanned aerial vehicle. Theone or more sources may include at least one of a broadcast beacon, awireless network identifier, a cellular tower, and a visual marker. Whenexecuted by a processor, the computer-executable instructions furthercause the processor to perform operations that include comparing thelocation data to the location and initiating an action based on thecomparison. The action may include landing of the unmanned aerialvehicle, returning the unmanned aerial vehicle to a previouslydetermined location, returning the unmanned aerial vehicle to a basestation associated with the unmanned aerial vehicle, requesting usercontrol of the unmanned aerial vehicle, or initiating self-destructionof the unmanned aerial vehicle.

In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include determining a range associated with the locationdata, determining a source location of the one or more sources of thelocation data, determining a distance between the location and thesource location, and comparing the range to the distance. In someembodiments, when executed by a processor, the computer-executableinstructions further cause the processor to perform operations thatinclude determining a source location of the one or more sources of thelocation data from a map that includes respective locations of the oneor more sources and determining a distance between the source locationand the location, and comparing the distance to a distance threshold.

In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include obtaining the visual marker from images or videocaptured by a camera of the unmanned aerial vehicle. In someembodiments, the one or more sources may further include the basestation. In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include determining a distance between a location of thebase station and the location and comparing the distance to the range ofthe base station.

In a second example embodiment there is disclosed an unmanned aerialvehicle having a processor and a non-transitory computer-readable memorystoring computer-executable instructions. When executed by a processor,the computer-executable instructions cause the processor to performoperations that include obtaining a location of the unmanned aerialvehicle engaged in autonomous flight. The location may be determinedfrom a satellite-based navigation system. When executed by a processor,the computer-executable instructions further cause the processor toperform operations that include determining location data from one ormore sources accessible by the unmanned aerial vehicle. The one or moresources may include at least one of a broadcast beacon, a wirelessnetwork identifier, a cellular tower, and a visual marker. When executedby a processor, the computer-executable instructions further cause theprocessor to perform operations that include comparing the location datato the location and initiating an action based on the comparison. Theaction may include landing of the unmanned aerial vehicle, returning theunmanned aerial vehicle to a previously determined location, returningthe unmanned aerial vehicle to a base station associated with theunmanned aerial vehicle, requesting user control of the unmanned aerialvehicle, or initiating self-destruction of the unmanned aerial vehicle.

In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include determining a range associated with the locationdata, determining a source location of the one or more sources of thelocation data, determining a distance between the location and thesource location, and comparing the range to the distance. In someembodiments, when executed by a processor, the computer-executableinstructions further cause the processor to perform operations thatinclude determining a source location of the one or more sources of thelocation data from a map that includes respective locations of the oneor more sources and determining a distance between the source locationand the location, and comparing the distance to a distance threshold.

In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include obtaining the visual marker from images or videocaptured by a camera of the unmanned aerial vehicle. In someembodiments, the one or more sources may further include the basestation. In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include determining a distance between a location of thebase station and the location and comparing the distance to the range ofthe base station.

In a third example embodiment there is disclosed a non-transitorycomputer-readable medium storing computer-executable instructions. Whenexecuted by a processor, the computer-executable instructions cause theprocessor to perform operations that include receiving a flight plan foran unmanned aerial vehicle, the flight plan including a flight path overa geographic area and comparing the flight path to one or moregeographically identified no-fly zones. When executed by a processor,the computer-executable instructions cause the processor to performoperations that include determining that the flight path does not enterthe one or more geographically identified no-fly zones, associating theflight plan with a cryptographic signature, and providing the flightplan for execution by the unmanned aerial vehicle.

In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include executing the flight plan after verifying thecryptographic signature. In some embodiments, associating the flightplan with a cryptographic signature includes signing a data object thatincludes the flight plan with the cryptographic signature. In someembodiments, the non-transitory computer-readable medium is a volatilememory of the unmanned aerial vehicle and the one or more geographicallyidentified no-fly zones and the cryptographic signature are stored in aprotected area in an address space of the memory. In some embodiments,when executed by a processor, the computer-executable instructionsfurther cause the processor to perform operations that includeannotating the flight plan with one or more policies along the flightpath. The one or more policies may include at least one of a no camerazone, an altitude restriction, a range restriction, and a speed limit.In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include establishing a connection to a server andreceiving the one or more geographically identified no-fly zones fromthe server. In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include determining an age associated one or moregeographically identified no-fly zones and determining that the age isless than an age threshold.

In a fourth example embodiment there is disclosed an unmanned aerialvehicle having a processor and a non-transitory computer-readable memorystoring computer-executable instructions. When executed by a processor,the computer-executable instructions cause the processor to performoperations that include receiving a flight plan for an unmanned aerialvehicle, the flight plan including a flight path over a geographic areaand comparing the flight path to one or more geographically identifiedno-fly zones. When executed by a processor, the computer-executableinstructions cause the processor to perform operations that includedetermining that the flight path does not enter the one or moregeographically identified no-fly zones, associating the flight plan witha cryptographic signature, and providing the flight plan for executionby the unmanned aerial vehicle.

In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include executing the flight plan after verifying thecryptographic signature. In some embodiments, associating the flightplan with a cryptographic signature includes signing a data object thatincludes the flight plan with the cryptographic signature. In someembodiments, the non-transitory computer-readable medium is a volatilememory of the unmanned aerial vehicle and the one or more geographicallyidentified no-fly zones and the cryptographic signature are stored in aprotected area in an address space of the memory. In some embodiments,when executed by a processor, the computer-executable instructionsfurther cause the processor to perform operations that includeannotating the flight plan with one or more policies along the flightpath. The one or more policies may include at least one of a no camerazone, an altitude restriction, a range restriction, and a speed limit.In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include establishing a connection to a server andreceiving the one or more geographically identified no-fly zones fromthe server. In some embodiments, when executed by a processor, thecomputer-executable instructions further cause the processor to performoperations that include determining an age associated one or moregeographically identified no-fly zones and determining that the age isless than an age threshold.

In a fifth example embodiment there is disclosed a method that includesobtaining a location of an unmanned aerial vehicle engaged in autonomousflight. The location may be determined from a satellite-based navigationsystem. The method further includes determining location data from oneor more sources accessible by the unmanned aerial vehicle. The one ormore sources may include at least one of a broadcast beacon, a wirelessnetwork identifier, a cellular tower, and a visual marker. The methodalso includes comparing the location data to the location and initiatingan action based on the comparison. The action may include landing of theunmanned aerial vehicle, returning the unmanned aerial vehicle to apreviously determined location, returning the unmanned aerial vehicle toa base station associated with the unmanned aerial vehicle, requestinguser control of the unmanned aerial vehicle, or initiatingself-destruction of the unmanned aerial vehicle.

In some embodiments, the method includes determining a range associatedwith the location data, determining a source location of the one or moresources of the location data, determining a distance between thelocation and the source location, and comparing the range to thedistance. In some embodiments, the method includes determining a sourcelocation of the one or more sources of the location data from a mapincluding respective locations of the one or more sources anddetermining a distance between the source location and the location, andcomparing the distance to a distance threshold.

In some embodiments, the method includes obtaining the visual markerfrom images or video captured by a camera of the unmanned aerialvehicle. In some embodiments, the one or more sources may furtherinclude the base station. In some embodiments, the method includesdetermining a distance between a location of the base station and thelocation and comparing the distance to the range of the base station.

In a sixth example embodiment there is disclosed an unmanned aerialvehicle having means for obtaining a location of the unmanned aerialvehicle engaged in autonomous flight. The location may be determinedfrom a satellite-based navigation system. The unmanned aerial vehiclefurther includes means for determining location data from one or moresources accessible by the unmanned aerial vehicle. The one or moresources may include at least one of a broadcast beacon, a wirelessnetwork identifier, a cellular tower, and a visual marker. The unmannedaerial vehicle also includes means for comparing the location data tothe location and initiating an action based on the comparison. Theaction may include landing of the unmanned aerial vehicle, returning theunmanned aerial vehicle to a previously determined location, returningthe unmanned aerial vehicle to a base station associated with theunmanned aerial vehicle, requesting user control of the unmanned aerialvehicle, or initiating self-destruction of the unmanned aerial vehicle.

In some embodiments, the unmanned aerial vehicle includes means fordetermining a range associated with the location data, determining asource location of the one or more sources of the location data,determining a distance between the location and the source location, andcomparing the range to the distance. In some embodiments, the unmannedaerial vehicle includes means for determining a source location of theone or more sources of the location data from a map having respectivelocations of the one or more sources, means for determining a distancebetween the source location and the location, and means for comparingthe distance to a distance threshold.

In some embodiments, when executed by a processor, the unmanned aerialvehicle includes means for obtaining the visual marker from images orvideo captured by a camera of the unmanned aerial vehicle. In someembodiments, the one or more sources may further include the basestation. In some embodiments, the unmanned aerial vehicle includes meansfor determining a distance between a location of the base station andthe location and comparing the distance to the range of the basestation.

In a seventh example embodiment there is disclosed a method thatincludes receiving a flight plan for an unmanned aerial vehicle, theflight plan including a flight path over a geographic area and comparingthe flight path to one or more geographically identified no-fly zones.The method further includes determining that the flight path does notenter the one or more geographically identified no-fly zones,associating the flight plan with a cryptographic signature, andproviding the flight plan for execution by the unmanned aerial vehicle.

In some embodiments, the method includes executing the flight plan afterverifying the cryptographic signature. In some embodiments, associatingthe flight plan with a cryptographic signature includes signing a dataobject that includes the flight plan with the cryptographic signature.In some embodiments, the method includes creating a protected area in anaddress space of a memory of the unmanned aerial vehicle and storing theone or more geographically identified no-fly zones and the cryptographicsignature in the protected area in the address space of the memory. Insome embodiments, the method includes annotating the flight plan withone or more policies along the flight path. The one or more policies mayinclude at least one of a no camera zone, an altitude restriction, arange restriction, and a speed limit. In some embodiments, the methodincludes establishing a connection to a server and receiving the one ormore geographically identified no-fly zones from the server. In someembodiments, the method includes determining an age associated one ormore geographically identified no-fly zones and determining that the ageis less than an age threshold.

In an eight example embodiment there is disclosed an unmanned aerialvehicle includes means for receiving a flight plan for an unmannedaerial vehicle, the flight plan including a flight path over ageographic area and comparing the flight path to one or moregeographically identified no-fly zones. An unmanned aerial vehiclefurther includes means for determining that the flight path does notenter the one or more geographically identified no-fly zones, means forassociating the flight plan with a cryptographic signature, and meansfor providing the flight plan for execution by the unmanned aerialvehicle.

In some embodiments, the unmanned aerial vehicle includes means forexecuting the flight plan after verifying the cryptographic signature.In some embodiments, associating the flight plan with a cryptographicsignature includes signing a data object that includes the flight planwith the cryptographic signature. In some embodiments, the unmannedaerial vehicle includes means for annotating the flight plan with one ormore policies along the flight path. The one or more policies mayinclude at least one of a no camera zone, an altitude restriction, arange restriction, and a speed limit. In some embodiments, the unmannedaerial vehicle includes means for establishing a connection to a serverand receiving the one or more geographically identified no-fly zonesfrom the server. In some embodiments, the unmanned aerial vehicleincludes means for determining an age associated one or moregeographically identified no-fly zones and means for determining thatthe age is less than an age threshold.

1. One or more non-transitory computer-readable media comprisingcomputer-executable instructions that, when executed by one or moreprocessors, cause the one or more processors to at least: compare aflight path over a geographic area of an unmanned aerial vehicle to ageographically identified no-fly zone, the flight path included in aflight plan; determine whether the flight path enters the geographicallyidentified no-fly zone; and based on whether the flight path isdetermined to enter the geographically identified no-fly zone, associatethe flight plan with a cryptographic signature.
 2. The one or morenon-transitory computer-readable media of claim 1, wherein theinstructions further cause the one or more processors to: attempt toverify the cryptographic signature; and when the cryptographic signatureis successfully verified, execute the flight plan.
 3. The one or morenon-transitory computer-readable media of claim 2, wherein theinstructions further cause the one or more processors to: determine anobstacle has been detected; based on the detected obstacle, calculate anew flight plan containing a new flight path; determine whether the newflight path enters the geographically identified no-fly zone; and basedon whether the new flight path is determined to enter the geographicallyidentified no-fly zone, associate the new flight plan with a newcryptographic signature.
 4. The one or more non-transitorycomputer-readable media of claim 1, wherein the flight plan isassociated with the cryptographic signature by signing a data objectthat includes the flight plan with the cryptographic signature.
 5. Theone or more non-transitory computer-readable media of claim 1, whereinthe one or more non-transitory computer-readable media include a memoryof the unmanned aerial vehicle, the one or more geographicallyidentified no-fly zone and the cryptographic signature stored in aprotected area of the memory.
 6. The one or more non-transitorycomputer-readable media of claim 1, wherein the instructions furthercause the one or more processors to annotate the flight plan with one ormore policies, the policies associated with one or more points on theflight path, the one or more policies including at least one of: a firstpolicy that restricts the usage of cameras by the unmanned aerialvehicle, a second policy that restricts an altitude at which theunmanned aerial vehicle is permitted to fly, a third policy thatrestricts a range of flight of the unmanned aerial vehicle, and a fourthpolicy that limits a speed at which the unmanned aerial vehicle ispermitted to fly.
 7. The one or more non-transitory computer-readablemedia of claim 6, wherein the flight plan is annotated with the firstpolicy at a first point on the flight path, and the instructions furthercause the one or more processors to enforce the first policy by shuttingoff a camera when the unmanned aerial vehicle is at the first point inthe flight path.
 8. The one or more non-transitory computer-readablemedia of claim 1, wherein the instructions further cause the one or moreprocessors to: establish a connection to a server; and access the serverto identify the geographically identified no-fly zone.
 9. The one ormore non-transitory computer-readable media of claim 1, wherein theinstructions further cause the one or more processors to: determine anage associated with data identifying the geographically identifiedno-fly zone; and determine whether the age of the data is less than anage threshold.
 10. The one or more non-transitory computer-readablemedia of claim 1, wherein the unmanned aerial vehicle is capable of atleast one of autonomous flight and user-controlled flight.
 11. Anunmanned aerial vehicle, comprising: one or more processors; a memoryincluding computer-executable instructions that, when executed, causethe one or more processors to at least: access a server to obtain aflight plan for the unmanned aerial vehicle, the flight plan including aflight path over a geographic area; compare the flight path to ageographically identified no-fly zone; and when the flight path does notenter the geographically identified no-fly zone, associate the flightplan with a cryptographic signature.
 12. The unmanned aerial vehicle ofclaim 11, wherein the instructions further cause the one or moreprocessors to execute the flight plan after verifying the cryptographicsignature.
 13. The unmanned aerial vehicle of claim 12, wherein theinstructions further cause the one or more processors to: determine anobstacle has been detected; based on the detected obstacle, calculate anew flight plan containing a new flight path; determine whether the newflight path enters the geographically identified no-fly zone; and basedon whether the new flight path is determined to enter the geographicallyidentified no-fly zone, associate the new flight plan with a newcryptographic signature.
 14. The unmanned aerial vehicle of claim 11,wherein the flight plan is associated with a cryptographic signature bysigning a data object that includes the flight plan with thecryptographic signature.
 15. The unmanned aerial vehicle of claim 11,wherein the instructions further cause the processor to: create aprotected area in an address space of the memory; and store dataidentifying coordinates of the geographically identified no-fly zone andthe cryptographic signature in the protected area in the address spaceof the memory.
 16. The unmanned aerial vehicle of claim 15, wherein thecomputer-executable instructions are stored in the protected area in theaddress space of the memory.
 17. The unmanned aerial vehicle of claim11, wherein the instructions further cause the one or more processorsto: annotate one or more points on the flight plan with one or morepolicies, the one or more policies associated with one or more pointsalong the flight path, and the one or more policies including at leastone of: a first policy restricting the usage of cameras by the unmannedaerial vehicle, a second policy restricting an altitude of the unmannedaerial vehicle, a third policy restricting a range of travel of theunmanned aerial vehicle, and a fourth policy limiting the speed of theunmanned aerial vehicle.
 18. The unmanned aerial vehicle of claim 17,wherein the flight plan is annotated with the first policy at a firstpoint on the flight path, and the instructions further cause the one ormore processors to enforce the first policy by shutting off a camerawhen the unmanned aerial vehicle is at the first point in the flightpath.
 19. The unmanned aerial vehicle of claim 11, wherein theinstructions further cause the one or more processors to: access a localstorage of the unmanned aerial vehicle to obtain encrypted coordinatesof the geographically identified no-fly zone; and decrypt the encryptedcoordinates of the geographically identified no-fly zone to obtain thegeographically identified no-fly zone.
 20. The unmanned aerial vehicleof claim 11, wherein the unmanned aerial vehicle is capable of at leastone of autonomous flight and user-controlled flight.